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Traceroute Using an IP Option 
Status of this Memo 


This memo defines an Experimental Protocol for the Internet 
community. Discussion and suggestions for improvement are requested. 
Please refer to the current edition of the "IAB Official Protocol 
Standards" for the standardization state and status of this protocol. 
Distribution of this memo is unlimited. 


Abstract 


Traceroute serves as a valuable network debugging tool. The way in 
which it is currently implemented has the advantage of being 
automatically supported by all of the routers. It’s two problems are 
the number of packets it generates and the amount of time it takes to 
run. 


This document specifies a new IP option and ICMP message type which 
duplicates the functionality of the existing traceroute method while 
generating fewer packets and completing in a shorter time. 
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Traceroute Today 


The existing traceroute operates by sending out a packet with a Time 
To Live (TTL) of 1. The first hop then sends back an ICMP [1] error 
message indicating that the packet could not be forwarded because the 
TTL expired. The packet is then resent with a TTL of 2, and the 
second hop returns the TTL expired. This process continues until the 
destination is reached. The purpose behind this is to record the 
source of each ICMP TTL exceeded message to provide a trace of the 
path the packet took to reach the destination. 


The advantage of this algorithm, is that every router already has the 
ability to send TTL exceeded messages. No special code is required. 
The disadvantages are the number of packets generated (2n, where n is 
the number of hops), the time it takes to duplicate all the nearer 
hops with each successive packet, and the fact that the path may 
change during this process. Also, this algorithm does not trace the 
return path, which may differ from the outbound path. 


Traceroute Tomorrow 


The proposed traceroute would use a different algorithm to achieve 
the same goal, namely, to trace the path to a host. Because the new 
traceroute uses an ICMP message designed for the purpose, additional 
information, unavailable to the original traceroute user, can be made 
available. 


2.1 Basic Algorithm 


A new IP Traceroute option will be defined. The presence of this 
option in an ICMP Echo (or any other) packet, hereinafter referred to 
as the Outbound Packet, will cause a router to send the newly defined 


ICMP Traceroute message to the originator of the Outbound Packet. In 
this way, the path of the Outbound Packet will be logged by the 
originator with only n+l (instead of 2n) packets. This algorithm 


does not suffer from a changing path and allows the response to the 
Outbound Packet, hereinafter refered to as the Return Packet, to be 
traced (provided the Outbound Packet’s destination preserves the IP 
Traceroute option in the Return Packet). 


The disadvantage of this method is that the traceroute function will 
have to be put into the routers. To counter this disadvantage, 
however, is the fact that this mechanism may be easily ported to a 
new IP version. 
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2.2 IP Traceroute option format 


0 8 16 24 
totat-t-t-t-t-t-to ssn a Sa a sn aa ai a eciaafa + 
|F | C | Number | Length | ID Number 
SAE A e a i E E EE toa Sse E treo Se + 
| Outbound Hop Count | Return Hop Count 
t------- 77-77 tone aS Se ae Hosa Seta eee ae ea + 
| Originator IP Address | 
t----- 77-77-77 t------- 7-77-77 t-------- a t----- 77-77-77 + 


F (copy to fragments) 
0 (do not copy to fragments) 
C (class) 
2 (Debugging & Measurement) 
Number 
18 (F+C+Number = 82) 
ID Number 
An arbitrary number used by the originator of the Outbound Packet 


to identify the ICMP Traceroute messages. It is NOT related to 
the ID number in the IP header. 


Originator IP Address 


The IP address of the originator of the Outbound Packet. This is 
needed so the routers know where to send the ICMP Traceroute 
message for Return Packets. It is also needed for Outbound 
Packets which have a Source Route option. 


Outbound Hop Count (OHC) 
The number of routers through which the Outbound Packet has 
passed. This field is not incremented by the Outbound Packet’s 
destination. 


Return Hop Count (RHC) 


The number of routers through which the Return Packet has passed. 
This field is not incremented by the Return Packet’s destination. 
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2.3 ICMP Traceroute message format 


0 8 16 24 

toa ssa PP Ga caer a oa toss toss ssa + 
| Type | Code | Checksum 
E E E ce S n EE TEE pihente 6 E ees E TEE + 
| ID Number | unused | 
e EEEN T A eE PR nA AR + 
| Outbound Hop Count | Return Hop Count 
prensi ea toss asa satan S + 
| Output Link Speed 
toss ssa toss toss toss saa + 
| Output Link MTU | 
toss E Farinha Sata + 
Type 

30 
Code 

0 - Outbound Packet successfully forwarded 


1 - No route for Outbound Packet; packet discarded 

Checksum 
The 16 bit one’s complement of the one’s complement sum of all 16 
bit words in the header. For computing the checksum, the checksum 
field should be zero. 

ID Number 
The ID Number as copied from the IP Traceroute option of the 
packet which caused this Traceroute message to be sent. This is 
NOT related to the ID number in the IP header. 

Outbound Hop Count 


The Outbound Hop Count as copied from the IP Traceroute option of 
the packet which caused this Traceroute message to be sent. 


Return Hop Count 


The Return Hop Count as copied from the IP Traceroute option of 
the packet which caused this Traceroute message to be sent. 
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Output Link Speed 


The speed, in OCTETS per second, of the link over which the 
Outbound/Return Packet will be sent. Since it will not be long 
before network speeds exceed 4.3Gb/s, and since some machines deal 
poorly with fields longer than 32 bits, octets per second was 
chosen over bits per second. If this value cannot be determined, 
the field should be set to zero. 


Output Link MTU 


The MTU, in bytes, of the link over which the Outbound/Return 
Packet will be sent. MTU refers to the data portion (includes IP 
header; excludes datalink header/trailer) of the packet. If this 
value cannot be determined, the field should be set to zero. 


Protocol 


The Outbound Packet which is used to carry the IP Traceroute option 
should use no special Type Of Service (TOS) or Precedence, unless the 
purpose is to trace the path of packets with special TOS or 
Precedence values. 


The TTL of the Outbound Packet should be set to the default value 
specified in "Assigned Numbers" [2]. 


3.1 Hop Counts 


The hop counts ultimately provide information on the length of the 
outbound and return paths to the destination. They also provide a 
means of determining whether or not any ICMP Traceroute messages have 
been lost. For example, if a Traceroute message with an OHC of 4 is 
followed by a message with an OHC of 6, then the the message with an 
OHC of 5 was lost. This is why simply counting Traceroute messages 
is not sufficient for determining path length. 


The originator of the Outbound Packet should set the OHC to zero and 
the RHC to OxFFFF. OxFFFF is a special value which indicates to 
routers that the packet is an Outbound Packet rather than a Return 
Packet (which begins with an RHC of zero). 


It is important to note that the Traceroute hop counts are NOT 
related to the IP TTL. A hop count should only be incremented when 
an ICMP Traceroute message is sent. 
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3.2 Destination Node Operation 


When a node receives an Outbound Packet with an IP Traceroute option, 
the Return Packet, if such is required (e.g., ICMP Echo 
Request/Reply), should also carry that option. The values in the ID 
Number, OHC, and Originator Address fields should be copied into the 
Return Packet. The value of the RHC field should be set to zero. 


The destination should NOT increment any hop counts or send any ICMP 
Traceroute messages. 


3.3 Router Operation 


When a router forwards a packet with an IP Traceroute option, it 
should send an ICMP Traceroute message to the host in the Originator 
IP Address field of the option. If the value of the RHC field is 
OxFFFF then the packet is an Outbound Packet and the OHC should be 
incremented; otherwise, the RHC field should be incremented. The 
Traceroute message should reflect the incremented hop count. The 
Output Link Speed field should be set to the speed, in OCTETS per 
second, of the link over which the Outbound/Return Packet will be 
sent (e.g., 1,250,000 for an Ethernet) or zero if the output link 
speed cannot be determined. The Output Link MTU field should be set 
to the MTU of the link over which the Outbound/Return Packet will be 
sent or zero if the MTU cannot be determined. 


The Outbound/Return Packet should be forwarded as though the 
Traceroute option did not exist; that is, it should take the same 
path to the destination as an optionless packet. 


The ICMP Traceroute message should have the same TOS and Precedence 
values as the Outbound/Return Packet. The TTL should be set to the 
default defined in "Assigned Numbers". 


The ICMP Traceroute message should not carry the IP Traceroute 
option. 


If the Outbound Packet cannot be forwarded, the ICMP Traceroute 
message should have a Code value of 1. If the Return Packet cannot 
be forwarded because there is no route, then there is no need to send 
a Traceroute message since it could not be forwarded either. 
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5. Security Considerations 


Security issues are not discussed in this memo. 
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